A typical enterprise may develop and maintain numerous software applications with which employees perform their day-to-day tasks. Depending on the enterprise, the number of applications utilized by employees may number in the hundreds, even thousands. Moreover, as these applications evolve over time, each application may have many different versions associated with it.
To manage these applications, an enterprise may define an internal software configuration management team (“SCMT”), consisting of an individual or individuals, which is responsible for storing applications and their many versions of source code as well as providing particular versions of these applications to users upon request. To aid in the performance of its job, the SCMT may develop enterprise software tools to automate software configuration management. One such tool may provide a means to store source code for jointly developed enterprise software applications in a central location and to permit an authorized developer to “check-out”, and later “check-in”, portions of an application. The developer may be responding to a “trouble ticket” which contains a problem description and fields identifying a particular application and its version. Another enterprise software tool may provide a means for an end user to generate a “trouble ticket” by selecting criteria, or values, from multiple menus, or listboxes, defined within that tool. Once the user makes all necessary value selections from listboxes defined within the tool, the user may submit the “trouble ticket” to have the problem addressed by the developers.
Although software configuration management may be automated in this manner, the task of installing, configuring, and supporting enterprise software like these configuration management tools has not been. As applications evolve and change, user-selectable criteria available within these configuration management tools, specifically listboxes and values defined within those listboxes, must also evolve and change to keep pace with the needs of the users and developers. After all, users must be provided with current criteria with which to identify desired applications for trouble reporting. Additionally, the list of authorized developers seeking access to source code may change frequently as developers leave the enterprise and others join. In response to such changes in manpower, access rights to the enterprise software must be frequently updated.
To maintain listbox values and access rights, users and developers submit their requests directly to the SCMT, which, in turn, must respond to each request individually by manually updating listboxes and/or defining access rights. In a large enterprise, a timely response to such user/developer requests is impossible. The SCMT becomes a bottle-neck in the configuration management process as the number of user/developer requests far exceeds the manpower available to answer them. Furthermore, the tasks of updating access rights and listboxes may be tedious and error-prone. Lastly, the actual act of updating enterprise software like these configuration management tools also creates problems because the software may need to be stopped prior to updating them, causing users/developers utilizing the tools to be booted from their sessions, thereby losing on-going work, and preventing others from accessing the tools.